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INTERACTIVE DATA MANAGEMENT SYSTEMS 


FOR AIRBORNE RESEARCH 
By Robert M. Munoz and John 0. Reller, Jr. 
Ames Research Center 


SUMMARY 


Computer- centered systems for acquisition and processing of research data 
are evolving into new and more effective configurations that employ several 
small-scale, interactive computers with attendant peripheral units. Software 
concepts and utilization are likewise changing to keep pace, both to optimize 
the functional reliability of system hardware, and to permit rapid and relia- 
ble reprogramming for diverse uses of system resources. 

Two such data systems have been developed by the Airborne Science Office 
(ASO) at Ames Research Center for use in airborne research. Both have "dis- 
tributed intelligence" and are programmed for interactive support among com- 
puters and with human operators. The C-141 system (ADAMS) performs flight 
planning and telescope control functions in addition to its primary role of 
data acquisition; the CV-990 system (ADDAS) performs data management functions 
in support of many research experiments operating concurrently. Each system 
is arranged for maximum reliability in the first priority function, precision 
data acquisition. 

The control and data management capabilities of these airborne systems 
will have their counterparts in Shuttle Spacelab installations, and will support 
research experiments in a similar manner. To the extent that these Spacelab 
systems can be made adaptable and interactive, they can enhance the perform- 
ance of scientists in the orbital research environment, and provide the means 
for optimum response to new or changing research opportunities. To this end, 
the present report of ASO experience may aid planning for Spacelab data 
management systems. 


INTRODUCTION 


The meteoric rise of minicomputers has had a profound effect on the 
design of modern data systems in recent years. The history of scientific data 
acquisition started with relatively simple measuring instruments, with the 
only intelligence being that of the investigator. But now in an age of 
nuclear fusion and men walking on the moon, experiments are performed in vehi- 
cles that orbit the earth; the intelligence of the investigator is augmented 
by a multiplicity of computers, while primitive recording methods have 
given way to reels of digital magnetic recording tape and large-scale com- 
puting complexes. It is certainly not our intent to review the entire 


1 



evolution of the design of scientific data systems, but we will outline one 
aspect of this evolution as it relates to the data systems used in the 
research aircraft of the Airborne Science Office at Ames Research Center. One 
motive for doing this is to provide a basis for further development in the 
design of future intelligent data systems, especially those of the Shuttle 
Spacelab in the orbital environment. 

The systems that we will describe here are far more than an aggregation 
of instruments in a vehicle. They consist of instruments, in part augmented 
by computers and recording devices, orchestrated by software to accommodate 
scientific and environmental changes, and controlled by several persons 
including systems operators and scientific investigators. The domain of the 
system encompasses both men and machines, software and hardware, not all of 
which is in the vehicle. The systems are adaptive and interactive. They per- 
mit changes from mission to mission and experiment to experiment, and within a 
single mission or experiment as well. This paper outlines the broader aspects 
of the total system, with an emphasis on components that perform their 
functions in flight. 

We begin with a brief review of basic environmental and operational 
constraints that have influenced the design of both airborne and orbital sys- 
tems. Some are similar in their impact; others appear inherently different, 
at least in historical context. We then discuss the details of design of two 
flight systems, the airborne data acquisition and management system (ADAMS) 
for the C-141 flying astronomical observatory and the airborne digital data 
acquisition system (ADDAS) for the CV-990 research aircraft. The major 
aspects of Ames' operational experience in applying these systems to the solu- 
tion of problems encountered in the research environment are reviewed. The 
paper concludes with a discussion of general principles synthesized from this 
experience that seem particularly relevant to trends in the evolution of 
intelligent scientific data systems. 


2 



PART I 


DESIGN PRINCIPLES AND APPLICATIONS TO 
FLIGHT SYSTEMS 
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BASIC CONTRAINTS OF FLIGHT AND SPACE ENVIRONMENTS 


Although the fundamentals of the design of Shuttle or other space data 
systems are of particular interest, such a discussion is clearly beyond the 
scope of this work, which is limited to an in-depth analysis of the airborne 
systems. However, in manned missions such as the Shuttle Spacelab, the envi- 
ronmental constraints are very nearly although not quite the same as those 
involved in the design of airborne systems. The following factors are illus- 
trative of some of the obvious simularities. For example, large jet aircraft 
such as the Convair 990 and the Lockheed C-141 have fairly benign environments. 
In the flight regime, temperatures may vary by about ±5" C at 25° C, and pres- 
sure altitude is normally at about 3 km (10,000 ft) but may vary from zero to 
6 km (20,000 ft) for short intervals. Mechanical vibrations and shocks in 
flight are entirely compatible with most normal laboratory instruments, as can 
easily be verified by one who has flown on a jet aircraft, but some attention 
must be paid to unusual G forces encountered in aircraft maneuvers, atmos- 
pheric buffeting, and takeoff/landing operations. Provisions must also be 
made for crew safety in emergency situations. Equipment must be solidly 
mounted or have the equivalent of seat belts to secure them against these G 
forces. 

On the other hand, there are some notably different constraints in 
aircraft and spacecraft. For example, jet aircraft are capable of carrying 
tremendous payloads economically, and can produce very large amounts of elec- 
trical power to supply equipment. These are two of the main areas of differ- 
ence between the airborne and the space environment; operationally, perhaps 
the more significant is the limitation of electrical power in a spacecraft. 

For approximately the same payload, the electrical power available to Shuttle 
Spacelab experimenters is of the order of 5 kVA, whereas approximately 20 kVA 
is available in both the CV-990 and the C-141. For the same payload weight, 
moreover, the vehicle operating cost is far greater in the space mission than 
in an airborne mission. Thus, conservation of weight would effect important 
economics, allowing more science per pound, or per dollar, if such a crude 
analogy is permitted. 

There is also a great difference in the psychological climates of the 
space and airborne missions. This difference has been built up over the years 
since Sputnik as a kind of "religion of rigorous concern for success." The 
primary tenet of this creed is R^QA (reliability and quality assurance) , and 
degrees of perfection are measured in terms of MTBF (mean time between fail- 
ure). This psychological climate drove the cost of previous space systems 
very high. Now, however, we have men in space in vehicles having the capacity 
to carry spares and to return to earth for new supplies or replacement parts. 
Thus, we can more nearly approach the philosophy of a tolerable level of 
correctable error that has been so much a part of the success pattern of 
airborne investigations. 
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AIRBORNE DATA ACQUISITION AND MANAGEMENT SYSTEM (ADAMS) 


System Design Guidelines 

The C-141 is a large military jet transport aircraft, which provides a 
platform for a 91-cm reflecting telescope, inertially stabilized and ideally 
suited to astronomical measurements in the infrared spectrum. The capability 
of flying at altitudes much higher than ground-based observatories makes this 
platform second only to space systems for eliminating the interfering effects 
of atmospheric water vapor in the observations. 

Guidelines for the design of the airborne data acquisition and management 
system (ADAMS) were defined primarily by the functions to be performed, within 
rather broad constraints on physical size, power consumption, and flight oper- 
ations parameters. From the first, the interactive role of the system was 
recognized, wherein the computer in response to programmed or real-time 
instructions from the operator (experimenter) would predict the optimum air- 
craft flight path and, when implemented, would orient the telescope for 
astronomical observations and track the selected target. 

In general terms, the priority function of the system was to acquire and 
record high-quality data from diverse experiments in the science of infrared 
astronomy, and to do so in a convenient and reliable manner over the long 
term. To this end, the design emphasis was on commercially available compo- 
nents of standard design that could be readily repaired or replaced. Such 
units were combined to minimize functional dependence on one another, and to 
provide redundant functions wherever possible, so that failure of one part 
would not destroy the effectiveness of the others. 

Additional guidelines required that the data system be expandable to meet 
future requirements and that it be compatible with other systems - namely, the 
data system on board the CV-990 research aircraft, and the larger ground-based 
computer systems at the Ames Research Center. Futhermore, the system was to 
accommodate rapidly to changes in experiments from mission to mission, and to 
variations in experiments within the same mission. The use of modular hard- 
ware and software was recommended as a primary aid in achieving these design 
goals . 

The data system was required to handle high-speed analog and digital data 
inputs (e.g., 15-bit precision at 10,000 wps) , perform specialized computa- 
tions such as co-adding and Fourier transformation, display diagnostic and 
quick- look information on experiments, and provide a post-processing capabil- 
ity sufficient to diagnose experiment faults and evaluate critical parameters 
between flights. Finally, telescope control, collection of avionics data, 
high-speed data acquisition, and computation of flight profiles were to be 
coordinated in flight to optimize scientific yield in the available flight 
time. 


In addition to the airborne data system, a ground-based simulation 
facility was required to support software development and experiment integra- 
tion. This facility was planned to functionally duplicate the 
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experiment-related processes o£ the flight data management system with a 
practical minimum of hardware, and was to be compatible with the flight data 
system of the CV-990 aircraft. 


System Functions 

Data acquisition and recording- The primary function of the ADAMS system 
is to acquire and record digital data from the main experiment on the tele- 
scope. To accommodate a wide variety of experiments, the system is flexible 
as to data rate, record size, data frame definition, intermediate handling 
[such as packing), and recording method. The highest priority of the system is 
to protect against total loss of data or data recording time on a flight. It 
contains sufficient redundancy to allow for individual component failure with- 
out catastrophic effect. 

To provide the flexibility required in a multiexperiment environment, 
data acquisition and recording is performed on a largely autonomous computer 
essentially dedicated to data-taking tasks. Data are accepted by the computer 
through an analog-to-digital converter (ADC) and stored on digital magnetic 
tape. Because the data rate is limited by the tape drive, abundant computing 
time is available for intermediate processing such as packing, minor 
conversions, or sync-pulse recognition. 

Software for these operations is provided as building blocks which have 
to be configured appropriately for each experiment. Modules provided include 
buffered input from the ADC, formating and buffered output to tape, start/halt 
control for both acquisition and recording, and other functions allowing vari- 
ous forms of experiment control and data communications. Custom software is 
generated for each experiment to provide timing and sequence control for the 
standard modules as well as any intermediate processing required. 

Primary experiment performance monitoring- One of the most important 
advantages of an on-line digital system is that it can provide the experi- 
menter with real-time monitoring of his results. This feedback to the experi- 
menter can enable him to avoid costly errors, discover instrument malfunctions, 
and generally make the best use of his limited observation time. 

The ADAMS system provides several forms of inflight processing for a 
powerful quick- look capability. First, raw data can be co-added to achieve an 
improved signal-to-noise ratio.* Second, co-added or raw data can be Fourier 
transformed to provide frequency spectra for display on a CRT device. Third, 
current raw data can be displayed on the CRT to check for signal quality. 
Fourth, special treatment such as windowing or filtering can be applied to the 
spectra. Finally, calibration data may be displayed for comparison with 
acquired data. 


*Co-adding is the accumulation of data components in an array where the 
elements of the array represent the sum of a number of similar components of 
an inter ferogram or a spectrum. 
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Software is provided to perform all these functions with the exception of 
nonstandard "special treatment" functions. The user specifies control param- 
eters for the standard functions (such as display scales) and provides control 
and timing software for interfacing his data with these functions. 

Environmental and engineering parameter recording- Experimenters 
generally require an accurate record of environmental parameters for post- 
processing of their data. The C-141 aircraft has a comprehensive set of these 
parameters available in the Central Air Data Computer (CADC) . Also, posi- 
tional data are available from the C-141 Inertial Navigation System (INS). 

Data are collected from these and other sources, automatically, at specified 
intervals. The data are recorded on magnetic tape, as well as displayed on a 
line printer. All of the software for this data- collecting function is pro- 
vided, although some of the parameters or functions of this software are 
transparent (unknown) to the user, and are initiated periodically by a 
hardware timer. 

If any of these parameters is required for intermediate processing of, or 
co-recording with, primary experiment data, the user can specify a block of 
the parameters required for his program. 

Flight planning and navigation- The C-141 data system is capable of 
generating a new or altered flight plan in the flight environment, which pro- 
vides the experimenter with additional flexibility in the use of his flight 
time. Typical uses of this system function are to lengthen or shorten a seg- 
ment of the flight to provide more viewing time or avoid wasting time; or to 
add or delete objects to be viewed, based on changing requirements. 

With the aid of the navigator, the computer generates constant-bearing 
flight paths for correct acquisition and maximum viewing time for single 
objects. The program runs in an interactive fashion in response to informa- 
tion supplied by the navigator, so that he can optimize the total flight plan 
and avoid undesirable (e.g., restricted) areas. As a subordinate function, 
the computer can be requested to monitor the flight's progress via the 
Inertial Navigation System (INS) and compare it with the current flight plan. 
Flight progress is displayed periodically for the user. 

Registration star chart display- As an aid in acquiring objects on the 
telescope, the ADAMS creates visual displays of local star fields for regis- 
tration with the objects viewed on the telescope monitor. The registration 
images are generated from a magnetic tape digital file of star locations, then 
displayed on the telescope monitors via a scan- converter device. Sample star 
fields can also be displayed by the user on a CRT device at scales other than 
those available on the monitors. The digital file of star locations has been 
created from the Smithsonian Star Atlas tapes. Many celestial objects are not 
sufficiently close to stars in the Smithsonian Atlas and require supplemental 
data for acquisition. An off-line facility is provided for entering this data 
into the star file to be used in flight. 

Offset-tracking support- Two functions are provided to assist the 
experimenter in the use of the facility's offset-tracking capability. First, 
the system will search its digital star file for suitable tracking objects. 
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given the primary object location. The experimenter is given a list of 
available tracking objects and he chooses the one to use. Second, once the 
experimenter has chosen the tracking object, the offset tracking parameters 
required by the wedge control system are calculated and sent to the system 
that controls the telescope position. The experimenter is thus relieved of 
computing and entering the parameters by hand. 

Raster scan- To provide an accurate scanning mode for the telescope, the 
system is capable of creating precise biasing voltages for the active tracking 
system. An interactive program has been devised that allows the experimenter 
to specify one of several types of geometric scan patterns, and to control the 
progress of the scan manually. 

Experimenter prograrming support- The system supports special program 
modules generated by both primary and secondary experimenters. Without 
greatly changing any of the utility software, it is possible to add experi- 
menter routines for conversion of raw data into engineering parameters for 
display in character or graphic form on one of several output display devices. 

Ground-based simulation and software development- An auxiliary ground- 
based data system containing many of the same components as the flight system 
is available for software development and experiment simulation. This system 
and the flight system (during nonflight hours) can be used for off-line proc- 
essing. This system can be used to produce copies of experimenter magnetic 
tapes, create new programs, and collate the Smithsonian Star Atlas tapes with 
new astronomical data of use to experimenters in flight. 


System Hardware 

The hardware in the ADAMS system (figs. 1 and 2) is of two types: 

(1) that exclusively dedicated to the use of the primary experiment, and 

(2) that used as a utility to service the secondary experiments, the avionics, 
and housekeeping functions. The former consists of one multiplex analog to 
digital converter (MUX/ADC) , a 16K core processor (the data processor) , two 
digital magnetic tape transports, and related peripheral equipment. Use of 
this equipment in acquiring and logging data is largely under the autonomous 
control of the experimenter. This kind of nearly autonomous operation permits 
greater flexibility and higher data rates than would otherwise be possible. 

It simplifies the hardware and software interfacing by permitting the experi- 
menter to develop his experiment on another identical or a similar processor 
before integration into the system. 

Figure 3 shows the relationship between the two types of equipment. A 
communication channel exists between the data processor and the executive 
processor, which is a key element of the support and housekeeping components. 
This permits bilateral software and data transfer under executive control. 

The hardware of the C-141 data system is designed to provide computing power 
for a wide range of applications, with a maximum of redundancy for system 
reliability. Considerable design effort has been devoted to the reduction of 
software and other development costs by adding hardware to spread out and 
simplify the software burden. 
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Figure 1 Operator 's console (ADAMS) in C-141 aircraft 






Figure 2.— Aft data system rack (ADAMS) in C-141 aircraft 
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Figure 5.— Block diagram of C-141 data acquisition and management system (ADAMS), 






























The data processor contains a fast Fourier transform arithmetic unit. 

This unit is primarily intended to serve the need for performing transforms on 
interferograms to produce quick-look displays of infrared spectra; it can be 
used for many other purposes, however, and is available to the experimenter. 

The experimenter's software is loaded into the data processor from the execu- 
tive processor. Developed software can be placed in the executive processor 
in the form of magnetic tape, paper tape, or disc cartridge and then 
transferred to the data processor. 

A second communication channel exists between the executive processor and 
the offset-tracking processor. This latter unit acts as a controller to drive 
two optical wedges that deflect the optical axis of the tracking telescope in 
relation to the main telescope. It also solves the geometric relationships 
necessary to properly position the tracker in accordance with commands 
received from the executive processor and initiated by the experimenter or the 
ADAMS operator under software control. The telescope operations and control 
loop is completed through the control console shovm in figure 4. 

The executive processor, containing a 32K word core memory, is used to 
perform utility functions such as interfacing with the IR telescope, aircraft 
systems, and secondary experiments, as well as handling most of the input/ 
output equipment used to control system parameters and provide displays and 
listings. Another function of the executive processor is to support the 
special requirements for aircraft navigation and for acquisition and tracking 
of celestial objects. 

Data enters the executive processor in many ways. The 15-bit multiplexer 
ADC is one means of entering relatively high-speed data from avionics and 
other sources. Another method of entering data is through the reed-scanner 
digital voltmeter, which is used to interface housekeeping channels and is 
limited to low data rates up to 40 samples per second. The multiprogrammer 
digital-to-analog converter (DAC) is equipped with one digital input card 
through which flag bits can be entered by manual keyboard into the executive 
processor. Similar inputs can be made through multipurpose duplex registers 
directly interfaced with the computer. 

The executive processor is equipped with a 2.4-Mword disc, which is used 
to archive program materials and a very limited amount of housekeeping data. 
For a normal mission, most of the housekeeping data are recorded on one of the 
two digital magnetic tape units attached to this processor. The other tape 
unit constitutes an archive of visible star data as an aid to celestial object 
acquisition and in navigation. Other peripherals of the executive processor 
serving utility functions include a video generator, paper tape punch, digital 
clock, line printer, hard-copy unit for the CRT, and a monitor oscilloscope. 

A complete equipment list is given in table 1. 


System Software 

The C-141 data management system is a real-time, dual-processor system 
with both interactive and automatic processing requirements. The general 
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Figure 4.— Telescope control console in C-141 aircraft 




Table 1. Equipment inventory for the ADAMS 


Data Processor 

Core memory; 16K, 16-bit words (expandable to 32K) 

Direct memory access unit (DMA); transfer rate IM-word/sec. 

Magnetic tape subsystem 1; 9 track, 115 cm/sec (45 ips) , 315 bytes/cm 
(800 bpi), 15-kHz rate 

Magnetic tape drive 2; 9 track, 115 cm/sec (45 ips), 315 bytes/cm (800 bpi), 
15-kHz rate 

Multiplex A/D converter (MUX/ADC); 15 bit, 8 channels, 18-kHz max. 

sampling rate 
Interface for MUX/ADC 
Pacer subsystem 

Fast Fourier transform arithmetic unit (FFT) ; 2048-word capacity 
Interface parallel duplex register 
Executive Processor 

Core memory; 32K, 16-bit words 
Time-base generator (TBG) 

Direct memory access unit (DMA) 

Interface for executive processor (2) 

I/O extender 

DMA for I/O extender 

Interface parallel duplex register 

Multiplex ADC; 15-bit, 32 channels, 45-kHz max. sampling rate 
Keyboard/ printer 
Digital plotter 

Line printer; 300 lines/min or better, 132 characters/line 
Graphics terminal (CRT); 300 characters/sec 
Video generator 

Hard-copy unit; 20 sec or less copy time 
Disc subsystem; 2.4M-word capacity 

Magnetic tape subsystem 3; 9 track, 115 cm/sec (45 ips), 315 bytes/cm 
(800 bpi) 

Magnetic tape drive 4; 9 track, 115 cm/sec (45 ips), 315 bytes/cm (800 bpi) 
Paper tape punch and interface; 75 characters/sec 
Paper tape reader and interface; 500 characters/sec optical 
Multiprogrammer DAC; 6 channels, 12-bit binary input, ±10.24 Vdc output 
Input card for multiprogrammer 
D/A card (6) 

Interface kit for multiprogrammer 

Radio receiver for National Bureau of Standards time signal from station 

Time- code generator 
Reed scanner 

Digital voltmeter (DVM) ; ±10-Vdc input 
Reed scanner/DVM interface, data source card 
Reed scanner/DVM interface, program contract card 
Reed scanner/DVM interface, scanner controller card 
Monitor oscilloscope 

Syncro-to-digital converter (SDC) ; 4 channels, 0 to 10-Vdc output 
Syncro-to-digital converter (SDC); 3 channels, ±10-Vdc output 
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performance requirements are for a high degree of reliability, flexibility, 
and simplicity of operation. To meet these requirements, the system has been 
designed to include elements of time-sharing, multiprogramming, and process 
control systems. The system has three on-line modes of operation: initiali- 

zation, command, and automatic. These "modes" can run concurrently, although 
the work they perform is essentially separate. The system also is capable of 
running off line as a conventional computer, using conventional operating sys- 
tems and languages such as Fortran IV. Figure 5 is a functional block diagram 
of the system software showing the basic relationships among the various 
modules. Software development consumed 3 to 4 man-years of effort to achieve 
flight status. 

Initialization motZe- The initialization mode occurs at the outset of each 
flight. It is supported by a special program designed specifically to estab- 
lish the configuring parameters for the use of the system by a particular 
experiment. This program is designed to allow the user the widest possible 
control over the work that the system is to perform while avoiding new pro- 
gramming that may cause unpredictable delays due to the generation of subtle 
errors or "bugs" always encountered in new software. 

The initialization program is interactive, collecting desired data via 
dialogue with the experimenter on the CRT terminal. A step-by-step procedure 
allows the user to specify or permit default conditions for all of the func- 
tions and their associated control parameters he intends to use. The 
information entered through this program includes: 

1 . Standard features on data computer 

2. Spectral displays on CRT, scales, display rate, etc. 

3. Special reduction features for spectral data 

4. Secondary data acquisition on executive processor 

5. List of housekeeping and secondary data to be printed, with the 
printing format 

6. Initial values for staple functions such as navigation 

The initialization mode docs not run concurrently with the other modes 
when it is used to initialize the system. It can be re-entered later, however, 
to make changes to the system configuration and, at that time, it will run 
concurrently with the automatic mode. 

In addition to its role in initializing the system, the initialization 
mode program loads the appropriate software into the data processor, loads 
software into the off-set tracking processor, begins the operation of the 
automatic mode, and enables the operation of the command mode. At the end of 
the operation of this mode, the program no longer occupies the core storage of 
the system. It can be reloaded and reexecuted, however, under control of the 
command mode. 

Command mode- The command mode represents the software interface between 
the data system on the one hand, and the experimenter, navigator, and operator 
on the other. It is the means by which the users of the system can command it 
to perform the various tasks that are not done automatically, such as star 
plot generation or flight planning. Table 2 lists the commands available to 
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Figure 5 ADAMS software block diagram 























Table 2. Conunand list (with mnemonic command codes) 


Keyboard Printer Command List 
(Operator or Navigator) 

CRT Command List 
(Experimenter) 

FL - Generate a New Flight Plan 

OT - Start Offset Tracking System 

ST - Store Flight Plan 

PL - Generate Registration Star Plots 

DU - Dump Flight Plan 

SD - Start Data Acquisition System 

WP - Check Way Points 

HD - Halt Data Acquisition System 

SP - Start Printout 

SR - Start Recording 

HP - Halt Printout 

HR - Halt Recording 

SS - Start System 

EF - End File on Magnetic Tape 

HS - Halt System 

CM - Enter Comment Line 

RC - Reconfigure Devices 

DP - Display Primary Experiment Data 

TD - Take Device Off Line 

DR - Display Primary Experiment Raw Data 

PD - Place Device On Line 

EX - Execute Experimenter’s Program 


RI - Re-Initialize 


RS - Perform Raster Scanning 
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the user. The commands are sent to the system by the users from either of two 
terminals. An interrupt initiated at the terminal causes the computer to read 
a command from that device. The command is then decoded and used to select an 
appropriate service routine from the program library. A group of such rou- 
tines runs concurrently with other system functions and even with other 
command routines, so the routines must be scheduled on a priority basis. 

The command set itself is divided into two groups; one for the experi- 
menter and one for the operator and navigator. This separation allows the 
essentially independent requests of the users to be entered simultaneously, so 
that there is no conflict in terminal utilization. If one terminal fails, 
however, all commands may be entered through the other one. 

As mentioned above, the command service routines run concurrently with 
other system functions. A carefully devised system of priorities prevents 
delays to time-sensitive programs and conflicts for I/O devices. Normally, 
the users are not able to see degradation in service of their commands from 
regular system functions. Highest priority is assigned to housekeeping data 
acquisition, which runs periodically and transparently to the user. Command 
service routines have the next priority. Longer commands, such as navigation 
and flight planning, can be interrupted by shorter commands, such as Halt 
Recording. The entry of any command interrupts any service routine, but the 
service of the command will wait until no higher priority program is active. 
Lowest priority is assigned to automatic data display to avoid I/O device 
conflicts . 

Automatic mode- The automatic mode programs are those that operate 
independently of the operator or experimenter. These programs are initiated 
by the system clock or by events in the system. They do not require the 
intervention of the users, and their execution is normally transparent to the 
users. The functions of the automatic mode include: 

1. Housekeeping data acquisition, recording and printing 

2. Communication with the data processor 

3. Hardware performance monitoring 

4. Way point checking of flight plan progress 

5. Spectral data displays 

6. Raster-scan control 

In addition to these executive resident functions, the data processor 
operations can also be considered to be in the automatic mode in that these 
programs generally operate without user intervention. The data processor pro- 
grams also may make use of blocks of data from the executive processor, and 
the executive processor will accept spectral data and hardware status data 
from the data processor. All of this communication is handled in the 
automatic mode. 

The automatic mode operations are started at the end of the initializa- 
tion mode, which ordinarily will be the beginning of a flight. Automatic mode 
operations continue unless the system is halted by the operator. Certain 
automatic operations, such as spectral displays and way-point checking, can be 
started or stopped independently of the other functions. 
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Automatic operations are executed concurrently with command programs and 
initialization programs (during reconfiguration). The automatic programs are 
generally short and do not create I/O device conflicts; therefore, they 
usually execute with high priority. 


AIRBORNE DIGITAL DATA ACQUISITION SYSTEM (ADDAS) 


Precursor Development 

A precursor to the present ADDAS system was assembled and flown in the 
original Ames CV-990 research aircraft between 1970 and 1973. Impetus for the 
development of this early system originated with the user community, in par- 
ticular to enable the simultaneous, time-coded recording of data from several 
closely related experiments in the payload of a single-purpose mission. Oper- 
ational experience with the precursor system for airborne data management pro- 
vided the essential ingredient in the successful development of both the ADAMS 
and ADDAS systems described in this paper. 

The heart of the precursor system was a data processor with a 16K core 
memory. Peripheral units were provided for input of analog and digital data 
from experiments, flight parameters from aircraft avionics, precise timing 
signals from the National Bureau of Standards radio station WWV, and experi- 
menter's comments via teleprinter. The data system could perform a limited 
amount of on-line data processing, in addition to recording in several media 
and displaying selected flight and experiment parameters on closed-circuit 
television. A block diagram of the precursor data acquisition system is given 
in reference 1 (fig. 7-A) . 

Experience gained with the earlier data acquisition system served to 
guide the design of the present ADDAS In particular, it was found undesir- 
able to have all data management functions resident in a single processor, 
where a fault in a secondary unit could interrupt the primary data acquisition 
function while repairs were effected. In practice, the functional redundancy 
was not sufficient to assure an uninterrupted data record, and individual 
experimenters often furnished their own backup recorders for critical situa- 
tions. The size of the precursor system (16K memory) and the rate of accept- 
ance of high-speed data (18 kHz) were also limiting factors, again requiring 
that some experimenters record their results independently. Even so, on major 
missions the data system was nearly always used to full capacity. 

Insofar as possible, both the hardware and software of the precursor 
system were in modular form to facilitate component maintenance and to mini- 
mize rewrite for the specific data handling requirements of successive mis- 
sions. Software development effort was estimated at two-man-years. The 
updating of utility subroutines for a specific mission took about one man-day, 
exclusive of special processing for new experiments; however, this activity 
required system regeneration for each new mission, which resulted in the 
generation of subtle errors and hence reduced software reliability. 
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The precursor system had some capability for postflight data processing 
and program changes to accommodate unexpected research results. Nearly all 
experimenters relied on time-correlated flight parameters recorded by the sys- 
tem, over half relied on accurate recording and printout of their experimental 
data, and about 40 percent required some inflight data processing (ref. 1). 

Use of the system increased steadily as its capability and flexibility were 
developed over a period of several years; the user community recognized its 
primary functions of accurate data acquisition and time correlation with data 
from other experiments or with flight parameters. 

On-line data processing was more limited both in quantity and in depth, 
reflecting not only the capacity of the data processor but also the experi- 
menter’s preference for local data acquisition units that gave continuous, 
real-time verification of data quality, as well as the availability of ground- 
based hardware for postflight evaluation of results.. 

Ground-based simulation of experiment hardware and software performance 
was accomplished primarily on board the CV-990, a procedure that required an 
intense application of manpower during final preparations for a mission and 
was clearly recognized as an undesirable constraint to optimum utilization of 
the system. 


System Design Guidelines 

Galileo II is a CV-990 commercial jet aircraft providing a second- 
generation airborne research laboratory used as a common platform for earth 
observations, astronomical observations, and similar scientific and engineer- 
ing measurements. The aircraft environment of Galileo II has the advantages 
of permitting the simultaneous operation of as many as ten experiments con- 
structed of normal laboratory apparatus, each operated by a scientist inti- 
mately familiar with it. The environment is relatively benign, and therefore 
compatible with commercially available minicomputers and peripheral components. 

A typical mission carries several experiments related to a single 
scientific discipline such as hydrology, meteorology, or earth science, and it 
is possible to benefit by the synergism that results from exchange of data 
among the experiments, particularly if this exchange can be implemented by the 
data system. For this reason, a serious effort has been made in the system 
architecture to permit several scientists to interact with a common data base 
in real time and process these data adaptively as the experiments progress. 

A mission may consist of several flights per week, for one to four weeks, 
after which all or most of the experiments will be removed and replaced with 
new experiments in preparation for the next mission. The data system there- 
fore must be flexible enough to change configuration rapidly. These demands 
can easily be met with the Airborne Digital Data Acquisition System (ADDAS) 
discussed in this section. 
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System Functions 


The Galileo II airborne data system is the critical part of the larger 
information processing system that begins with the data sensors on the air- 
craft and ends with the publication of scientific results. It bears the major 
responsibility for acquisition and recording of high-precision data of a qual- 
ity that justifies the effort and expense of further ground-based data reduc- 
tion so necessary for scientific analysis and interpretation. The primary 
function of the system is to acquire and record high-quality data from the 
experiments and from the avionics, which give flight status and housekeeping 
parameters. Recordings are made on digital magnetic tape during a flight, and 
copies of this tape are distributed after each flight to the community of 
users . 

The system produces a number of displays of vital signs for quick- look 
verification of performance to guarantee data quality. These displays give 
the experimenters a feel for how their individual experiments perform and how 
the mission is progressing as a whole. The system also permits experimenter 
interaction with the data base in real time, as noted earlier, enabling experi- 
menter preprocessing of data samples, correlation of data from experiments and 
avionics, and diagnosis of doubtful data streams. Primary data are recorded 
on digital magnetic tape. Secondary output media, produced by a listing 
machine and plotting equipment, are also used for quick-look and diagnostics. 

A typed log of each flight, annotating events of interest, is recorded with 
the data and aids in reconstructing the flight situation and identifying 
unusually interesting data events. The log is entered into the system through 
a keyboard by the mission stenographer. 

The data system controls experiments requiring adaptively computed inputs 
in response to a change in experiment or environmental parameters. One 
example is the computation of ground speed per unit altitude. This informa- 
tion is supplied in analog form to control earth-observations camera film 
speed. The system also synchronizes all avionics and experiments according to 
a master clock and provides many forms of digital time code and time displays 
for various purposes. Since time is the independent parameter for all experi- 
ments, it is used as the basis for correlating all control, monitoring, and 
logging functions. Processes within the system are timed and controlled to an 
accuracy of better than 1 msec. 


System Hardware 

Figure 6 is a block diagram of the hardware configuration of the 
Galileo II data system, consisting of a complex of minicomputers, peripherals, 
and ancillary peripheral equipment. It illustrates the relationship between 
the two processors - the data processor, which is used mainly for data logging, 
and the executive processor, which performs most of the other system functions, 
including managing peripherals and experimenter interaction. 

Data originating in scientific experiments normally are in analog and 
digital form. The analog data are of two types: (1) high-speed experiment 

data, which enter the data processor through one of two redundant 15-bit 
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Figure 6.— Hardware configuration of Galileo II data system (ADDAS) 






































analog-to-digital converters; and (2) low- speed housekeeping data, which enter 
through the crossbar scanner digital voltmeter (DVM) . All signals of this 
type can be monitored at a central patch-panel located in the data control 
center. For signals requiring amplification, high-precision analog preampli- 
fiers with noise-filtering capabilities are normally installed close to the 
sensor signal source. 

Digital interfaces to the experiments are made through the input/output 
channels of the data processor. This is normally done through controllers and 
data interface cards that are standard accessories to the computer; under 
special circumstances, however, it is possible to install custom interfaces 
designed and fabricated by the experimenter. Aircraft flight parameters enter 
the data system from the CADC, the INS, and the Doppler Radar System (DRS) 
through synchro-to-digital converters and directly in digital form. The 
synchro information is first converted to dc and then to digital form in the 
multiplexer ADCs. A special custom interface to the processor is provided 
for digital data from the INS. INS data on longitude, latitude, true heading, 
and other flight parameters, are updated every 1.6 sec and incorporated by 
software into the main data stream. Other data enter the data processor 
through the communications link with the executive processor. 

After entering the data processor, data are formated and merged before 
being recorded on a 9-track digital magnetic tape at a density of 315 bytes 
per cm (800 per in) and 115 cm per sec (45 in/sec), giving a maximum practical 
word rate of approximately 13,000 wps. 

The executive processor is equipped with a dual -cartridge disc memory 
system, which permits it to operate like a miniature computations center with 
multiprogramming capability. It can be used to assemble Fortran- and machine- 
language programs to interact with the data processor and the experimenter’s 
interactive terminals, and for many other functions discussed in the next 
section (software). 

Data enter the executive processor through the communications link and 
through the time-code generator. Control signals and comments enter through 
the control terminal, the experimenter's interactive terminal, and the type- 
writer terminal. Software and data can also be entered through the medium of 
paper tape via the paper tape reader, or through the replaceable cartridge of 
the disc memory system. The time-code generator is the heartbeat of the sys- 
tem, providing inputs to the computers and other components of the system 
synchronized with universal time by a WWV receiver calibration link. The 
generator also provides time displays throughout the aircraft. 

Data outputs from the executive processor are produced on the line 
printer and the XY plotter, and displayed on television sets distributed 
throughout the aircraft as selected flight and experimenter parameters. In 
addition, the hard-copy unit is capable of recording graphical and alpha- 
numeric information from the CRT control terminal and the CRT experimenters’ 
interactive terminals. Digital-programmable voltage sources are used to 
output dc voltages for experiment process control. 

It is a major objective of the data system to survive equipment failures, 
and dual hardware redundancy has been designed into the architecture for this 
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reason. Although each component is necessary for a full operating system, any 
one of the computers, magnetic tape transports, ADCs or line printers could 
fail, and the basic data logging function would survive with only minor degra- 
dation. Many other types of functional redundancy are possible through repro- 
gramming software, patching, and interchange of identical interfacing 
circuitry. As we gain experience in system use, the more important survival 
configurations will be preprogrammed and made available under software control. 
Table 3 lists the equipment for ADDAS; the arrangement of subsystems in 
standard aircraft racks is illustrated in figures 7 through 13. 


System Software 

Because of the changing nature of CV-990 missions, the data system must 
be reconfigured readily and reliably. Certain functions of the data collec- 
tion process must be protected from accidental experimenter intervention. 

These problems can be solved only through a judiciously selected and meticu- 
lously developed software set. System software must support a multitude of 
tasks such as initializing, data logging, data display, and experimenter 
interaction. It must also coordinate the two computers and peripherals ' 
attendant to each. For these reasons, we have selected two coexisting soft- 
ware operating systems, one for the executive processor and one for the data 
processor, integrated by means of a communications link and functioning in a 
multiprogramming environment. 

The first operating system installed in the executive processor is a 
real-time executive, disc-based system. It has the capability of core- and 
disc-resident modules operating in a timesharing mode to perform functions 
simultaneously or sequentially on command of the control terminal. Within 
this environment, programs or software modules have been written to initialize 
the data system, arrange formats, and produce output displays, listings, and 
plots. The environment supports assembly language, Fortran IV, and a "Basic" 
interpreter. 

The second system is a fairly low overhead core-centered "Basic Control 
System" operating in the data processor. This system supports machine- 
language modules developed in the executive processor and installed using a 
cross loader through the communications link that connects the two processors. 
All computer-to-computer transactions take place through this link. 

Initialization of the ADDAS is similar to that of the ADAMS discussed 
earlier and is performed by a program operating interactively to ask the oper- 
ator to specify channel assignment, data rates, and formats for configuring 
each mission-specific software set. The program permits modifications to the 
data to be made in Fortran or assembly language for display of engineering 
parameters. During initialization, no other simultaneous software functions 
are normally permitted within the executive processor. After initialization, 
the data processor is cross loaded and can be run autonomously. 
Re-initialization and program modification during a flight is possible, but 
other functions within the executive processor must temporarily be suspended. 
The initialization process makes it possible to gather INS and other house- 
keeping data, to produce permanent records on magnetic tape, and to display 
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Table 3. Equipment inventory for the ADDAS 


Data Processor 

Core memory; 24K 

Magnetic tape subsystem 1; 9 track, 115 cra/sec (45 ips) , 315 bytes/cm 
(800 bpi) 

Magnetic tape drive 2; 9 track, 115 cra/sec (45 ips), 315 bytes/cm (800 bpi) 
Multiplex A/D converter (MUX/ADC) ; 15-bit, 96 channels (2) 

Crossbar scanner/digital voltmeter 
Line printer 1 

Data control center (patch panel) 

Voltage calibration source 

Precision analog preamplifiers with variable bandwidth LP filter 
Quartz thermometer 
Monitor oscilloscope 

Inertial navigation system (INS) interface 
Synchro-to-dc- converter system 
Executive Processor 
Core memory; 32 K 

Disc storage; 2.4M-word, dual cartridge 

Voltage calibration sources 

CRT control terminal (character and vector) 

CRT experimenters' interactive terminals (character and vector) 

Line printer 2 

Power control center (patch panel) 

Drum plotter 

Paper tape reader and punch 
Typewriter terminal 

Digital-to-television converter (graphics generator/ scan converter) 

Hard-copy unit 

Time-code generator 

WWV receiver 

TV display monitors 
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Figure 7.— Data control center (ADDAS) in CV-990 aircraft. 
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Figure 8.— Executive and data processors (ADDAS) in CV-990 aircraft. 
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Figure 9.— Magnetic tape recorders and TV monitor (ADDAS) in CV-990 aircraft. 
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Figure 10.— Plotter, hard-copy unit, and voltage calibrators (ADDAS) in CV-990 

aircraft . 
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Figure 11 Typewriter terminal and line printer (ADDAS) in CV-990 aircraft 




Figure 12.— Interactive terminal and printer (ADDAS) in CV-990 aircraft. 




Figure 13.— Control terminal (above) and paper tape systems (ADDAS) in CV-990 

aircraft. 
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information on the television monitors, the line printer, the plotter, and the 
interactive terminals. The software is parameter driven to allow variations 
suitable to the mission-specific requirements while still maintaining a highly 
reliable software set that has been debugged and proven beforehand. This 
allows a fairly short turnaround time between flights. 

After initialization, the executive processor is capable of running a 
timeshared "Basic’’ language interpreter, in lieu of the real-time executive, 
to support experimenter interaction with a data base stored in the disc 
memory. This data base contains a comprehensive record of the most recent 
10 min of data and a decimated record of approximately 1 percent of the data 
recorded throughout any single flight. The experimenter may perform any oper- 
ation on his data, and the data from other cooperating experiments, if it can be 
supported by "Basic." Such operations as statistical comparisons, plotting 
the data of one experiment with that of another, filtering, and integration 
can be programmed and run on individual terminals simultaneously. 

The executive processor can also develop, compile, and run Fortran 
programs, but not at the same time it is supporting timeshared "Basic," 

Neither timeshared "Basic" nor Fortran special routines interfere with the 
normal data system functions of the data processor, that are protected after 
initialization. The software operating systems are fairly flexible and capa- 
ble of supporting the continuously changing requirements of the aircraft 
research environment without abandoning useful previous developments. 


GROUND-BASED SIMULATOR 


In support of both the ADAMS and the ADDAS airborne intelligent data 
systems, we have constructed a ground-based system of components that are com- 
patible with, and in some cases identical to, their flight equivalents. This 
system is configured to support the functions of software development, experi- 
ment preprocessing, limited data postprocessing, and simulation. 

The largest software development task is the development of systems and 
applications software of a general-purpose nature, applicable to the flight 
data systems no matter what the experiment configuration. However, there is a 
continuing need to support the special requirements of each new experiment as 
it is prepared for flight. Some, but not all, of this support can be accom- 
plished in the aircraft systems, because of the incompatibility of merging the 
operational aspects of an ongoing mission with the special requirements of 
integrating software for new experiments and missions. The logistics and 
maintenance requirements of the aircraft make it difficult or impossible to 
predict the availability of services, and there are times when only the 
ground-based facility is available for use. 

In the area of experiment preprocessing, this facility is used to 
translate experiment-specific software from source language into a code com- 
patible with the aircraft operation. Data from punched paper tape, punched 
cards, digital magnetic tape, and disc cartridges are made available to the 
flight systems in a suitable form. In addition, the system is used to compute 
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support data and experiment calibrations before flight. Postflight 
processing is done to evaluate some data on a limited basis, and on occasion 
to translate data into other formats. This pre- and postflight processing is 
a relatively minor aspect of the use of the ground-based system, however, 
because other ground-based facilities of much greater capability are normally 
used by the investigators in the course of data reduction. 

Simulation of the flight data systems is useful to prevent abortive 
attempts at installing equipment in the aircraft before it has been proven 
compatible and productive. The ground-based facility when used in this capac- 
ity forms a first step in the process of experiment integration. Then a 
successful experiment is integrated into flight hardware in an expeditious 
manner. 
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PART II 


OPERATIONAL EXPERIENCE 
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DEDICATED FACILITY (C-141 ADAMS) 


Integration and Checkout 

Installation of ADAMS hardware was completed in late January 1974, and 
full-system debugging commenced using the standard utility and diagnostic 
software supplied as part of the total contract effort. By late March, hard- 
ware checkout and software integration was sufficiently complete that ADAMS 
could provide on-line experiment support. Meanwhile, in the January to March 
period, three experiments were flown on the aircraft to evaluate the perform- 
ance of telescope optics, stabilization, and tracking systems. 

The first experiment to use the ADAMS was a Fourier interferometer for 
planetary spectroscopy in the 1.5- to 6-p range. In preparation for this 
experiment, a special-purpose software program was generated to process raw 
data into interferograms . Data from previous (ground-based) observations were 
supplied by the experimenter, who then compared the resulting interferogram 
with that from his own computer program. Agreement was good, and the 
experiment-specific software was verified. 

The data system performed satisfactorily during three flights with this 
experiment in early April, but the local environment created by the telescope 
stabilization system (vibration and EMI) had a significant adverse impact on 
data quality. The next experiment, a Michelson interferometer for spectros- 
copy of far IR sources, had internal difficulties and did not achieve on-line 
operation with the data system on two flights. 

The third experiment utilizing the ADAMS was a far IR photometer system 
for mapping the galactic center, and was conducted in a four-flight series in 
early June. In this case, data were acquired and stored, and no on-line proc- 
essing was required. The data system operated as programmed and, once the 
pickup of vibration and EMI by the experiment from the telescope systems was 
resolved, several good-quality, high-resolution scans of W51 were obtained. 
These scans provided apparently unique data on this astronomical object in the 
far IR region. 

This flight series brought to a close the initial operational shakedown 
of the entire facility. The ADAMS was shown to be performing its primary 
functions of accurate data acquisition and recording; on-line processing of 
experiment data was also demonstrated. Computer- control led telescope tracking 
and scanning is now functioning on a routine basis; further software develop- 
ment is being done as the full system capability comes into use. 


Preflight Simulation 

When the telescope simulation laboratory is fully implemented, preflight 
verification of the experimenter's flight package will largely be done there, 
and final integration with aircraft systems will occur on the day of the first 
scheduled flight. The simulation laboratory will duplicate aircraft 
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mechanical and electrical interfaces, and will provide optical facilities for 
alignment and focusing on target sources, as well as data processing equipment 
that is functionally equivalent to the ADAMS. Present plans do not include 
simulation of flight environment parameters, such as pressure, vibration or 
EMI; these must be accounted for in the design and testing of the experiment 
prior to arrival at Ames, using values given in the C-141 Experimenters' Hand- 
book (ref. 3) or by special arrangement with the ASO/AIRO facilities manager. 
(Experience to date has shown that vibration and EMI problems do exist but are 
amenable to solution.) 

As noted, the simulation laboratory is presently fitted with ADAMS 
components for translation and verification of experiment-specific software. 

A typical user will relay his software plans and format to Ames about two 
months before a scheduled flight series, preferably as proven and debugged 
software modules written in Fortran or assembly language compatible with that 
used in the data management system, but if necessary in equation form for 
coding and integration by ASO support personnel. Integration times have 
varied from one week to one month, but should consistently approach the 
shorter period as aircraft utilization rises to full operational capacity. 

The data system components assembled in the simulation laboratory are 
used for both ADAMS and ADDAS program development. In this capacity, the 
utilization factor of the laboratory is currently in excess of 50 percent of 
time available. This equipment is also a ready reserve to replace 
malfunctioning flight units. 

Software -equipment data interactions in real time are not sufficiently 
documented to report at present. This area will be addressed in forthcoming 
publications . 


Utilization and Support Manpower 

Utilization of the C-141 data management system was relatively modest 
during the facility shakedown period from March to June 1974. Data from 
primary experiments were recorded and processed, and those from two secondary 
experiments were recorded as well. The secondary experiments were a water- 
vapor radiometer, and a far IR modular interferometer that measures the upper- 
atmosphere emission spectrum. Both were used as background diagnostic devices 
for the primary experiment, but also yielded scientific results of their own. 
They are being retained as semi -permanent installations. The interferometer 
experiment has, at present, a built-in computer that communicates with the 
ADAMS system for data and software, but processes the data separately from the 
ADAMS record. Final recordings of the processed data are made by ADAMS on 
magnetic tape. 

Present software programs allot about 20 percent of the data processor 
capacity to recording functions and 40 percent to on-line processing of exper- 
iment data. The remainder, about 40 percent, is uncommitted. The executive 
processor is operating at about 60 percent of capacity when all present 
software is functioning. 
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Personnel to support both ADAMS and the CV-990 ADDAS operations are drawn 
from a common manpower pool for more effective response to fluctuating demand. 
All personnel (a total of four or five) have access to the simulation labora- 
tory for software development, and dual training is the rule. On C-141 
flights during the facility shakedown period, two ADAMS operators and two 
telescope operators participated in the training program, while primary exper- 
iment support consisted of the principal investigator and two associates. Now 
that routines are established, direct in-flight support of these three sys- 
tems - the ADAMS, the telescope, and the primary experiment - requires three 
people, although some backup is desirable for the experimenter on flights of 
typically eight hours duration. 


MULTIPURPOSE FACILITY (CV-990 ADDAS) 


Integration and Checkout 

Design studies for the ADDAS system were initiated in late September 1973 
and had developed to the hardware procurement stage by January 1974. System 
logic and the functional roles of hardware and software were developed in 
accordance with the basic concepts of the ADAMS system, but with specific 
adaptations reflecting the multi experiment mode of operation and the base of 
operational experience with the CV-990 precursor system. 

Software development also began in September 1973, using the precursor 
package to indicate which format and data processing methods had proved suit- 
able for past missions. About 3 man-years were required to complete the cur- 
rent operational software, including that for the first expedition, an 
international meteorological program, referred to as the CARP Atlantic Tropical 
Experiment (GATE), which is in progress. 

Hardware integration and checkout began on June 1, 1974 with concurrent 
software verification in the simulation laboratory. Final onboard checkout of 
the primary recording functions was completed before the first engineering 
check flight on June 25. Minor modifications to secondary data management 
functions and software control were completed during the early flights of this 
initial ADDAS mission. A full functional operating capability has been 
achieved, although some software development continues during the day-to-day 
flight operations. 


Preflight Simulation 

The multiexperiraent payloads characteristic of CV-990 missions are not 
amenable to full-scale preflight simulation in a ground-based facility. Pres- 
ent practice is to integrate experiment and support-systems software (as far 
as possible) in the simulation laboratory, usually without signal inputs from 
experiments. Final software verification takes place on the ADDAS in the air- 
craft during experiment installation. This approach follows the pattern 
developed for the precursor data system (as an interim measure) , but tends to 
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shift the burden of experiment-specific programming from the experimenter to 
the ASO data system manager. In turn, the manager's knowledge of experiment 
data characteristics (at best second-hand) may delay the resolution of some 
software problems unnecessarily. As the full potential of the new ADDAS for 
on-line experiment support is realized, it will be necessary to accommodate a 
larger portion of the preflight simulation of both hardware and software in 
ground-based facilities prior to experiment integration into aircraft systems. 


Utilization and Support Manpower 

Initial installation and checkout of ADDAS hardware was accomplished in 
the five weeks just prior to the remote-based GATE mission'. Experiment 
installation and onboard hardware/ software verification took place in the last 
three weeks of this period, and two local checkout/data flights were made to 
complete the premission preparations. Since this was the first use of the 
ADDAS, support manpower and man-days of effort were far in excess of normal; 
upwards of eight people were involved at various stages, for an estimated 
60 man-days of effort - 

Eleven experiment systems and four aircraft support systems were on board 
for this mission, and all delivered input data to the ADDAS for recording. 

Raw data were processed for each experiment. Overall about 70 percent of data 
processor resources and 30 percent of the executive processor resources were 
utilized. 


SYNTHESIS OF OPERATING PRINCIPLES AND INDICATED 
FUTURE DEVELOPMENTS 


Present developments indicate that the basic nature and capabilities of 
intelligent data systems are in a period of rapid evolution, caused in part by 
the availability of inexpensive minicomputers and peripheral equipment, and in 
part by new ways of thinking about data from the software point of view. To 
characterize this evolution, the more significant trends are extracted from 
our current design and operational experience, and used to extrapolate toward 
the systems of the future. 

It appears that intelligent data systems are tending toward groupings in 
which the functions of intelligence are distributed, with interaction and 
mutual support for overall system reliability and effectiveness. Both the 
ADAMS and ADDAS systems have multiple, relatively autonomous computers. This 
suggests that future intelligent data systems may have more interconnected 
computers communicating with one another. This could come about through the 
microprocessors that are currently becoming available as large-scale, inte- 
grated, semiconductor elements. They find application now in portable calcu- 
lators. In the future, however, they may be associated with experiments in 
which data streams that are now analog may become digital data buses, and 
one-way data flow may become bilateral digital communications. A fore taste 
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of this development has been proposed in recent data management concepts for 
the Shuttle Spacelab (ref. 2), with separate, dedicated microcomputers for 
experiment control and monitoring. The failure of a microprocessor or micro- 
computer would impact only the experiment to which it is attached while the 
rest of the system could survive intact. 

We have also seen a marked increase in interaction between man and 
machine to the benefit of both. Artificial intelligence gives the technologi- 
cal capability of reducing or eliminating the repetitious tasks of data log- 
ging, calibration, and conversion of data to a form of display suited to human 
analysis. With this capability has come the problem of specifying in software 
how it is to be deployed for any given experimental situation. The systems 
discussed here have demonstrated that this problem can be reduced by permit- 
ting experimenters a range of options to be selected at will to accommodate 
changing situations. Human judgment and interaction can turn the basic rou- 
tine of raw data acquisition into a viable, adaptive experience of information 
retrieval and evaluation. This suggests that the future intelligent data sys- 
tem will be characterized by a vital interaction between experimenter and 
hardware, with a larger amount of research information and less raw data. 

More processing will be done at or near the sensor and condensed data forms 
such as statistics images and spectra may augment or replace the present 
serial data streams. Interactive display devices will very likely become more 
convenient and personal, and perhaps be hand-held, personalized versions of 
the present keyboard CRT. 

In software development, experience has shown a great reduction in fixed- 
purpose modules and an increase in parameter-driven adaptive modules, orches- 
trated by an executive program according to the needs of a particular mission. 
Continuing this trend, the future should see the writing of software of the 
greatest generality - program generators that will permit the rapid and reli- 
able reprogramming of data systems to accommodate even large changes in the 
uses and characteristics of the available computer resources. This will also 
provide an immediate improvement in functional reliability, permitting failed 
components to be programmed out of critical uses, and redundant or spare 
components to be applied to higher priority tasks. 

In the broadest view, our experience has shown an increase in the 
capacity of intelligent data systems to gather and process more information at 
less cost than was heretofore possible. If this trend continues, the chal- 
lenge of the future will be to propose more useful experiments and make better 
application of the information obtained. 
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SHUTTLE SPACELAB APPLICATIONS 
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SHUTTLE SPACELAB APPLICATIONS 


The evolution o£ research-oriented data management systems has been both 
accelerated and given new direction by the very rapid development of computer- 
related technology in the last few years. Design philosophies are changing 
and new logic patterns are being applied to produce flexible, adaptive systems 
that are increasingly interactive with other devices and with human operators. 

Recent advances in airborne data handling systems illustrate these trends 
and point up design concepts that appear relevant to analogous Spacelab sys- 
tems. In brief, we have seen that: 

1. Distributing intelligence among several relatively antonoraous 
computers enhances reliability with respect to the primary function, the 
acquisition and recording of precision scientific data. Alternate processors 
and subsystems can be programmed to assume primary roles in the event of 
component failure. 

2. Software format is evolving in the direction of parameter-driven 
adaptive modules, coordinated by an executive program according to the spe- 
cific needs of a particular mission. In this direction lie functional and 
programming reliability with ready accommodation to diverse demands on 
existing resources. 

3. Experiment-dedicated microcomputers with interactive display devices 
will allow increased processing and interpretation of experiment data at the 
source, with condensed data forms rather than streams of raw data flowing into 
a central recording system. 

4. Software requirements are reduced and the range of options is 
increased when human judgment and direct interaction with data systems operate 
in response to the changing situations or unexpected events that inevitably 
occur in the course of scientific research. 

These innovative design trends serve to enhance rather than reduce the 
role of man in Spacelab research. Supported by an intelligent data system, 
the trained scientist can undertake tasks of greater magnitude and complexity 
than heretofore, and by effective use of interactive hardware and software, he 
can accomplish these tasks in less time and with greater precision. 
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